1. The Field of the Invention
The present invention generally relates to the transfer of messages between endpoints in a service oriented system. More specifically, the present invention provides for a runtime communication channel with pluggable modular channel components that utilize one of a set of standard interfaces. Such a system allows processing details of communication semantics between channel components to be represented in a polymorphic way.
2. Background and Related Art
Computer systems and related technology affect many aspects of society. Indeed, the computer system's ability to process information has transformed the way we live and work. Computer systems now commonly perform a host of tasks (e.g., word processing, scheduling, database management, etc.) that prior to the advent of computer systems were performed manually. More recently, computer systems have been coupled to one another to form computer networks over which the computer systems can communicate electronically to share data. Service oriented systems (e.g., Web Services) have been a driving force in advancing such communications between computer systems and is turning the way we build and use software inside-out.
Service oriented architectures let applications share data, and—more powerfully—invoke capabilities from other applications without regard to how those applications were built, what operating system or platform they run on, and what devices are used to access them. Typically, these systems are invoked over the Internet by means of industry-standard protocols including SOAP (Simple Object Access Protocol), XML (extensible Markup Language), UDDI (Universal Description Discovery Integration), WSDL (Web Service Description Language), etc. Although these services remain independent of each other, they can loosely link themselves into a collaborating group that performs a particular task.
Often, electronic communication in a service oriented network includes a client computer system (hereafter referred to as a “client”) requesting access from a network service(s) (e.g., Web Services) at a server computer system (hereinafter referred to as a “service”). Accordingly, the client sends a request to the service for particular access to its system resources, wherein if the client is authorized and validated, the service responds, e.g., with a response message providing the desired information. Of course, other message exchange patterns between a client and a service (as well as other communication semantics described below) are available and include simple singleton messages as well as more sophisticated multi-message exchanges like, e.g., notifications, solicit-response, pub-sub patterns, polling, queuing and others.
To generate a service, a developer writes source code (e.g., C#, C++, or Visual Basic) in accordance with a specified programming model. The source code can then be compiled into a service type and the service type executed in a server runtime to provide the service to client consumers. Different programming models, however, can implement distributed messaging functionality in different ways. For example, one programming model can implement both a request message and a corresponding reply message using a single interface that has separate methods. The single interface can have one method for the request message and a second different method for the corresponding reply message.
Different programming models can also be configured in accordance with different communication semantics. For example, each model can have different encoding, transports, security options, reliable messaging options, message logging options, connection throttling options, etc. Thus, two services that are designed to implement the same functionality (e.g., performing a mathematical operation) may implement the functionality differently.
Further, distributed applications are typically rigid in their programming models allowing only one programming model that is tightly coupled to their service runtime. Accordingly, for compatibility, a client runtime (e.g., at a service consumer) is typically required to utilize a client program or module developed in accordance with the same programming model as the server runtime. For example, if a service was developed using separate interfaces for request and reply messages or uses a particular message encoding and transport protocol, the service consumer must implement those as well. Failure to use a client program or module developed in accordance with the service runtime.
Such rigidity and tight coupling to the specific communication semantics specified by the service developer have several inherent drawbacks. For example, typically companies use proprietary network communication semantics to distribute services within its own network. They may have specific requirements for security, reliability, type of transport and encoding to use, etc. If that company acquires another company (e.g., through a merger or acquisition), the acquired companies systems must also be able to implement these specific communication semantics or protocols. Such requirement, however, is very unlikely and as such the acquired company's applications (or acquiring company's applications) must be rewritten or configured to conform to the specified communication semantics.
As can easily be seen, such reworking and/or reconfiguration can be costly and does not accurately reflect the fundamental purpose of service oriented architectures (e.g., Web Services), which is to provide services to a multitude of devices in an environment agnostic way. Accordingly, there exists a need to model communication semantics in an extensible and pluggable way in order to make the system more flexible to changing needs.